[3주차] 임현성/[feat] 팀 내 요구사항에 맞는 게시글 API 구축#99
Hidden character warning
[3주차] 임현성/[feat] 팀 내 요구사항에 맞는 게시글 API 구축#99HyeonSeongIM wants to merge 1 commit intoLeets-Official:임현성/mainfrom
Conversation
| public enum ResultType { | ||
|
|
||
| SUCCESS, ERROR | ||
|
|
There was a problem hiding this comment.
코드 작성하시느라 수고 많으셨습니다.
enum으로 ResultType을 정의해서 숫자 상수 대신 명확한 타입으로 상태를 표현한점이 좋은 것 같습니다.
| if (posts.isEmpty()) { | ||
| throw new PostException(ErrorType.NOT_EXIST_POST); | ||
| } |
There was a problem hiding this comment.
게시글이 없는 경우도 예외 처리로 하신 것 같은데, 서비스를 시작한 초기 상태처럼 게시글이 아예 없는 경우에도 예외가 발생하게 되는 건지 궁금합니다!
There was a problem hiding this comment.
서비스 역할별 파일 구조가 잘 분리되어 있는 것 같아요!! 배워갑니다!~!
| @Transactional | ||
| public Post update (Long postId, Post post) { | ||
|
|
||
| Post savedPost = postRepository.findById(postId).orElseThrow(RuntimeException::new); |
There was a problem hiding this comment.
PostFinder에서는 커스텀 예외를 사용하고 계신 것 같은데, PostManager.update()에서는 RuntimeException을 사용하신 이유가 있을까요?
There was a problem hiding this comment.
예외 핸들러가 정말 깔끔하네요! 특히 ErrorType에 따른 로그 레벨 분기는 운영 시 불필요한 노이즈를 줄여주는 세심한 설계인 것 같아 인상 깊습니다.
저도 공부하다 알게되어 한 가지 제안을 드리자면, ResponseEntity 대신 ResponseEntity>처럼 타입을 명시해보는 건 어떨까요?
현재 방식도 동작에는 문제가 없지만, Swagger 같은 문서화 도구를 사용하는 경우 응답 스펙을 자동으로 인식하지 못하는 경우가 있어서, 타입을 구체화하면 API 스펙 공유나 협업 측면에서 도움이 될 수 있을 것 같습니다!
4 participants
1. 과제 요구사항 중 구현한 내용
2. 핵심 변경 사항
3. 실행 및 검증 결과
4. 완료 사항
5. 추가 사항
closed #이슈번호제출 체크리스트
{이름}/main브랜치다{이름}/{숫자}주차브랜치다Reviewer 참고